-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement locking service #15
base: main
Are you sure you want to change the base?
Conversation
@@ -0,0 +1,27 @@ | |||
@startuml Locking Service Sequence Diagram |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PUML is a diagram generator we use at Microsoft, it's free and is a nice way to create pictures from text.
You can generate the diagram by copying this into the bottom of the plant uml website or downloading a local viewer (there's a vs code extension called PlantUml by Jebbs that has some instructions on that)
Also here's a link to the image
|
||
# use exponential backoff to try again without flooding network | ||
while not lock_acquired: | ||
rospy.loginfo("Couldn't acquire the lock, trying again") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider changing to a debug message instead, this will pop up whenever a node is waiting on the lock every once in a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to run me through how to implement this into RobotModule. :')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually lets make sure to implement the ui before pulling
Why make this change?
Our current locking system is always-preemptable, which is fine for our use case but isn't ideal as it means the driver has to be pretty careful with the way they launch scripts, as running some scripts over others might get us into an undefined state.
What changed?
Added new classes
LockServer
andLockClient
, which uses a ros service to implement a mutex which also gives signals to enable control from the UI via the topic/ui/enablement
Also cleaned up the directories in
robot_module
and modified some of the imports to make them more consistent with other areas of the codebase.How was it tested?
Tested
LockServer
class by runninglock_service_server.py
and sending messages usingrosservice
.Also created a test file showing how to use
LockClient
,example_lock_client.py
, and verified that it can be executed (assuming nothing's holding the lock already).Also double checked that
test.py
is still runnable after making changes to the imports.